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1 SYSTEM AND METHOD FOR MANAGING 

2 MAINTENANCE OF BUILDING FACILITIES 

3 The present invention generally relates to a system and a 

4 method for managing maintenance of building facilities. More particularly, 

5 the invention relates to a system and a method for managing maintenance 

6 of building facilities using data transfer between a server computer and a 

7 plurality of client computers, each having a unique login identity. 

8 The management of maintenance in building facilities 

9 typically involves several processes that often have not been effectively 

10 defined or integrated with one another in the past. To effectively carry out 

11 such management processes, there must be a process for inspecting the 

12 building facilities to determine what tasks have been done and what tasks 

13 need to be done, and these tasks can change according to various schedules. 

14 To have an efficient overall system, other effective processes must be 

15 provided, including a work request process, a work order process, a 

16 schedule tracking process, and a notification process. In most known 

17 conventional systems, most of these processes have been done manually in 

18 that they have been at least partially done with the use of considerable 

19 human intervention, which is inefficient, costly and time consuming. In 

20 addition, massive human intervention in a complex system tends to cause 

21 more errors. For example, a customer's inspection orders, work requests, 
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1 and work orders have often been lost or not processed, which often results 

2 in considerable customer dissatisfaction. 

3 There are computer-implemented systems that attempt to 

4 reduce the use of human intervention at various steps of such complicated 

5 building facilities management maintenance. However, these systems do 

6 not fully integrate the whole maintenance system. Most of them simply 

7 allow customers to communicate with vendors over the web, and do not 

8 provide an integrated system that minimizes the need for unnecessary 

9 human intervention. Such systems often are unable to offer customization 

10 of each building facility that can result in greater precision and organization 

11 in the maintenance management system. 

12 Accordingly, it is a primary object of the present invention to 

13 provide an improved system and method for automatically and efficiently 

14 managing maintenance of building facilities with minimal human 

15 intervention. 

16 Another object of the present invention is to provide such an 

17 improved system and method that permits robust customization that can be 

1 8 tailored to each building facility. 

19 Still another object of the present invention is to provide such 

20 an improved system and method that permits simple and quick 

21 communications between the customer and the vendor. 

22 Yet another object of the present invention is to provide such 

23 an improved system and method that can use mobile computing devices 

24 that can configured to display selective data for each assigned job site. 

25 A further object of the present invention is to provide such an 

26 improved system and method that can operate on a worldwide scale using a 

27 large-scale network, such as the Internet. 
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1 BRIEF SUMMARY OF THE INVENTION 

2 The present invention is directed to a method and a system for 

3 managing maintenance of a building facility using data transfer between 

4 one or more server computers and one or more client computers. The 

5 system and method allows full integration of the maintenance management 

6 process using a computer-implemented system to minimize human 

7 intervention and increase system efficiency and accuracy, while reducing 

8 operating costs. 

9 More particularly, the system and method are adapted to 

10 utilize one or more client computers connected via a large-scale network 

11 such as the Internet to a server with a central database. Such client 

12 computers can be personal computers, other computers, or mobile 

13 computing devices, such as PDA's as well as cell phone devices. Any of 

14 these devices will hereinafter be referred to simply as a client. From the 

15 central database, job sites are tracked and monitored for fulfillment of 

16 inspections, work requests, work orders, or any other scheduled items. In 

17 addition, the present invention can automatically send out requests or 

18 events responsive to data stored in the central database without human 

19 intervention. As a result, the system is adapted to customize each job site 

20 and maintain precision and organization with minimized human 

21 intervention. 

22 In accordance with an important aspect of the present 

23 invention, the system includes one or more server adapted to receive events 

24 from a client and forward the events to a clearinghouse via a 

25 communication link, one or more client having a unique login identity and 

26 adapted to selectively send events to the server via the communication link, 

27 and a clearinghouse connected to each server and each clipnt via the 

28 communication link for selectively storing data from each server and each 

29 client in a database. The clearinghouse is further adapted to selectively 

30 authorize predetermined events by each client according to the login 
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1 identity of each such client, to selectively schedule predetermined events in 

2 response to data stored in the database and to monitor the status of all 

3 events stored in the database. 

4 DESCRIPTION OF THE DRAWINGS 

5 FIGURE 1 is an exemplary schematic diagram of a network 

6 system in which the present method can be implemented; 

7 FIG. 2 is a schematic diagram of the components 

8 implemented in the present invention; 

9 FIG. 3 is a flow chart illustrating the overall general scheme 

10 of the present invention; 

11 FIG. 4 is a flow chart illustrating a preferred mobile 

12 computing device session; 

13 FIG. 5 is a flow chart of the download-tasks event; 

14 FIG. 6 is a flow chart of the upload-tasks event; 

15 FIG. 7 is a flow chart of the perform-task event; 

16 FIGS. 8a through 8d illustrate example displays of the mobile 

17 computing device; 

18 FIG. 9 is a flow chart illustrating an overall scheme of a 

19 session initiated by a user (i.e., a maintenance person) of a client, not using 

20 a mobile computing device with preloaded software described in FIGS. 4 to 

21 8, for connection with the server; 

22 FIG. 10 is a flow chart of the job site-setup event; 

23 FIG. 1 1 is a flow chart the contact-setup event; 

24 FIG. 12 is a flow chart the vendor-setup event; 

25 FIG. 13 is a flow chart of the inspection-setup event; 

26 FIG. 14 is a flow chart of the checklist-item-setup event; 

27 FIG. 15 is a flow chart of the performance-rating-method- 

28 setup event; 



4 



1 FIG. 16 is a flow chart of the performance-rating-type-setup 

2 event; 

3 FIG. 17 is a flow chart of the special-action-setup event; 

4 FIG. 18 is a flow chart of the inspection-templates-setup 

5 event; 

6 FIG. 19 is a flow chart of the schedule-setup event; 

7 FIG. 20 is a flow chart of the inspection-processing event; 

8 FIG. 21 is a flow chart of the notification event; 

9 FIGS. 22a through 22c comprise a flow chart of the work- 

10 request event; 

1 1 FIG. 23 is a flow chart of the work-request-processihg event; 

12 FIGS. 24a and 24b comprise a flow chart of the work-order 

13 event; 

14 FIG. 25 is a flow chart of the work-order-processing event; 

15 FIG. 26 is a flow chart of the general scheme of the 

16 scheduling process; and, 

17 FIG. 27 is a flow chart of the general scheme of the 

1 8 monitoring process. 



1 9 DETAILED DESCRIPTION OF THE INVENTION 

20 Broadly stated, the present invention is directed to a system 

21 and a method for managing operational facilities; the system or method 

22 being of the type that utilizes predefined events to carry out managing 

23 operations for the facilities. The system includes at least one server adapted 

24 to receive events from a client and forward the events to a clearinghouse via 

25 a communication link. In addition, the system includes at least one client, 

26 but preferably hundreds if not thousands of clients, each of which having a 

27 un ique lo gi n ident ity, adapted to selectively send events to the server via 

28 the communication link. Also included in the system is a clearinghouse 

29 connected to each server and each client via the communication link for 
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1 selectively storing data from each server and each client in a database. The 

2 clearinghouse is further adapted to selectively authorize predetermined 

3 events by each client according to the login identity of each such client, to 

4 selectively schedule predetermined events in response to data stored in the 

5 database and to monitor the status of all events stored in the database. 

6 It is contemplated that the present invention can be 

7 implemented for various operational managing systems, such as janitorial, 

8 electrical, plumbing, drywall, lawn care, plant care, waste removal, parking 

9 lots, and roofing. In addition, other operational managing systems are also 

10 contemplated. For example, a heating, ventilating, and air conditioning 

1 1 (HVAC) system or a window cleaning, installation, and repair system can 

12 also be implemented with the present invention. Other examples include 

13 energy management, carpentry and general repair, pool maintenance, 

14 boilers and furnaces maintenance, lighting and signage maintenance, and 

15 tree trimming. Although the previous examples focus mainly on the facility 

16 operational maintenance, the present invention contemplates other 

17 managing systems dealing with different entities, such as property 

18 management, security guards, tenants of commercial office buildings, 

19 elevator services, fire protection services, equipment maintenance, 

20 appliance repair, furniture repair, road repair, trucking services, and locks 

21 and access control systems. It is further anticipated that the present 

22 invention can be implemented with all kinds of inspection systems for 

23 safety, water and soil sampling, aviation, boat, ship, plumbing code, 

24 electrical code, and surveyors. 

25 Another implementation relates to the medical services. For 

26 example, the present invention can manage home use medical equipment 
ft and home nursing care. An addition, customer and vendor related services, 

28 such as a biding servicp, can also be included within the present invention. 

29 For example, the bicTding service provides a gateway for a customer to 

30 propose bids to many vendors in a single transaction, which benefits both 
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1 the customers and/vendors. As a result, the customers are connected to the 

2 vendors mope efficiently, reducing the overall management time for 

3 transacjkms. 

4 ' The present invention can add another dimension in facility 

5 management with an employee tracker system, for example. Employees 

6 can carry a mobile computing device ("MCD") with customized data for 

7 completing a specific task, while the MCD incorporates a Global 

8 Positioning System ("GPS") for tracking the employee. The coordinates 

9 registered from the GPS can be integrated into the different events almost at 

10 any time in the process depending on the type of event involved. For 

11 example, the coordinates can be logged whenever the user answers a 

12 question proposed during an event or upon completion of an event. 

13 Another alternative is logging the coordinates once during the opening of 

14 the event and another time when the same event is closed. The logged 

15 coordinates can either be sent to the server as data for storage in the 

16 database or be included in the events that are created in response to the 

17 processing of the previous event. 

18 The GPS can ensure that the employees having MCD's were 

19 actually at the site at a specific time to complete a particular task. Another 

20 example is implementing the present invention in a trucking business for 

21 dispatching and tracking the use of the trucks and trailers. The 

22 implementation can change with the customer's demands or the needs for 

23 special customization. For example, the present invention requires 

24 different customization if the customer is an insurance adjuster. Other 

25 examples include property appraisers, case workers, probation officers, and 

26 telecommunication and cable installers, which all require different 

27 customizations. Basically, the present invention can be implemented for 

28 any system with complex management interrelations with various 

29 components in the system. As a result, there are many ways to implement 
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1 the present invention, and these other alternatives or modifications are 

2 within the scope of the present invention. 

3 Turning now to FIG. 1, the system in which the present 

4 method can be implemented is generally indicated as part of a preferably 

5 wide area network 10. A plurality of client computers ("clients") 12 is 

6 connected to a plurality of network servers ("server") 14 via the network 

7 10. As an example, the clients 12 can be network servers, which in turn are 

8 connected to workstations 16 within an intranet. In addition, the present 

9 invention can be implemented using a variety of connections, such as the 

10 Internet or wireless communication system. The connection functions 

11 primarily to allow the server and the client to communicate and transfer 

12 data preferably but not necessarily using real time communication. 

13 However, the Internet is the preferable network connection 8 

14 because it provides the most flexible and universal way of communicating. 

15 If the Internet is used as the communication connection between the client 

16 12 and the server 14, Extensible Markup Language (XML) is the preferred 

17 language for its implementation. However, the present invention can be 

18 implemented practically in any number of ways that may evolve with 

19 evolving technology. To further the complexity of the various network 

20 types that may be available, issues of bandwidth, reliability and security of 

21 the network are important considerations. As a result, an explanation of the 

22 current preferred embodiment of the network topology is given as an 

23 example and other networks and connections are within the scope of the 

24 present invention. 

25 A schematic diagram of the components implemented in the 

26 present invention is shown in FIG. 2, and includes a clearinghouse 18 

27 linked to a database 20. The database 20 acts as a central storage location 

28 for the data 22 for each building facility. The clearinghouse 18 is, among 

29 other things, the management system for the present invention. The 

30 clearinghouse is directly linked to the database 20 for inputting and 
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1 extracting data 22 from the database for further communication with one of 

2 the servers 14, which is also connected to one or more clients 12. The 

3 server 14 is, among other things, a gateway for the client 12 to 

4 communicate with the clearinghouse 18. 

5 Although the data involved is generally a text file or database 

6 file containing textual and numerical information, the present invention 

7 contemplates the use of other data formats for use with graphic, audio and 

8 video files. Presently, the current available bandwidth speed makes it 

9 difficult, if not impracticable to send photographs or video over the 

10 transmission. However, as bandwidth increases and technology improves, 

1 1 the implementation of these types of data is very feasible. For example, an 

12 inspector can send an image of an area that needs to be further attended by 

13 a staff member. Rather than using only textual language, a description with 

14 the use of visual data makes communications between parties more clear 

15 and efficient. The present invention, therefore, contemplates the use of 

16 visual and audio data in addition to purely textual data as an 

1 7 implementation within the present invention. 

18 Both the clearinghouse 18 and the client 12 can create events 

19 24 that trigger certain predefined actions from any of the components 

20 depending on the type of the event. In addition, data 22 can be transferred 

21 between the clearinghouse 18 and client 12, and the clearinghouse in turn 

22 saves or retrieves the data from the database 20. Although these 

23 components are shown as a separate unit, they can be placed in a single 

24 unit. For example, for a smaller scale implementation, it may be preferable 

25 for the server 14 to contain both the clearinghouse 18 and database 20. In 

26 contrast, it may be preferred that all the components remain in separate 

27 computers for a larger scale implementation. The arrangements of these 

28 components can vary and are within the scope of the present invention. 

29 A flow chart of the overall general scheme of the present 

30 invention is shown in FIG. 3 for an overall system that has events that 
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1 generally interact with each other. The events of work-request 26, job site- 

2 setup 28, inspection-setup 30, scheduling 32, notification 34, and 

3 monitoring 36 are all integrated and can interact with one another within 

4 the system. In addition, the client 12, which generally represents a vendor 

5 which may supply goods and/or services or a customer of the entity which 

6 operates the system, can initiate these events, which in turn can trigger 

7 other events, such as a work-order 38 and inspections-processing 40. The 

8 client 12 itself can also trigger some of the events, specifically a work- 

9 request 26, a job site-setup 28, an inspection-setup 30, a notification-34, a 

10 work-order 48, and an inspection-processing event 40. Also, the 

1 1 clearinghouse 1 8 can initiate any of the events. 

12 The interaction among these events is generally maintained 

13 by the clearinghouse 18. For example, the work-request event 26 can 

14 initiate the work-order event 38 and vice versa. The inspection-processing 

15 event 40 interacts with both the inspection-setup event 30 and the 

16 notification event 34 at a certain point in the process. A more detailed 

17 explanation of how certain events relate and react to one another will 

1 8 follow below in order to provide a clear understanding of how the system 

19 works as a whole. 

20 As previously mentioned, the client 12 can be a mobile 

21 computing device, and a customer or a vendor can login on the system 

22 using the client. In the case of a vendor using a client for processing a 

23 subroutine, such as inspection processing 42, the client 12 is preferably a 

24 mobile computing device. The client 12 also is preferably preloaded with 

25 certain data according to the assigned job sites of the user of the device. 

26 Since the login of these mobile computing devices is different from a client 

27 that is a personal computer, specific processes are provided for the devices, 

28 which are shown in FIG. 4. 

29 Although a process for the MCD with preloaded data and 

30 software is provided in FIG. 4, the present invention contemplates using 



10 



1 portable devices with wireless Internet access, such as a Personal Digital 

2 Assistant or Pocket PC. The MCD, in this case, responds or sends events 

3 preferably by connecting to the web page directly on the MCD. As a result, 

4 there is no need to preload the MCD with software or data. The needed 

5 data will be displayed through the web page. In this instance, the MCD 

6 does not need the process described in FIG. 4. This alternative 

7 implementation is within the scope of the present invention. 

8 The flow chart of FIG. 4 illustrates a preferred mobile 

9 computing device ("MCD") session, which is triggered by the device user 

10 (block 42). The process begins (block 44) by the user starting a client using 

11 software that was previously installed and specifically designed for the 

12 MCD 12, which will be referred to as the task list program ("TLP") (block 

13 46). The MCD 12 next enters a username and a password to sign onto the 

14 server 14 (block 48), and checks whether the login was successful (block 

15 50). If the login was unsuccessful, the MCD 12 displays an error message 

16 from the server 14 explaining why the login failed (block 52). 

17 If, on the other hand, the login was successful (block 50), the 

18 MCD 12 will establish a connection with the server and start 

19 communicating with the server for downloading of the task list (block 54). 

20 The MCD 12 then downloads the task list in an in-box designed for the 

21 login identity of the user from the server (block 56), which initiates a 

22 download-tasks event (block 58) shown in FIG. 5 and will be explained in 

23 greater detail below. After the download-tasks event has been processed 

24 (block 58), the MCD next uploads completed tasks in its out-box for this 

25 user (block 60), which initiates the upload-tasks event (block 62) shown in 

26 FIG. 6 and will again be explained later in great detail. 

27 Because a successful login gives the MCD a specific user 

28 identity matching stored information in the database, the user of the MCD 

29 still has a choice to download tasks, upload tasks, perform a task, or exit the 

30 TLP (block 64) with or without a specific user identity. If the user wants to 
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1 download tasks from the server (block 64), the download-tasks event is 

2 initiated (block 66). Similarly, the upload-tasks event is initiated (block 62) 

3 if the user chooses to upload tasks to the server (block 68). If the user 

4 chooses to perform a specific task on the MCD (block 64), a perform-task 

5 event is initiated (block 70) which is shown in FIG. 7 and will be described 

6 in detail. Finally, the user can also exit the process (block 72) by choosing 

7 to exit the TLP (block 64). 

8 A flow chart of the download-tasks event 66 is shown in FIG. 

9 5, and is initiated by the MCD (block 74), and the process begins (block 76) 

10 with the MCD checking the connection with the server (block 78). If the 

11 MCD is not connected, the user has to login using a username and 

12 password (block 80). Then, it is checked again if the login was successful 

13 (block 82). If not, the MCD displays an error message from the server 

14 (block 52) and brings the user back to the choices of downloading tasks, 

15 uploading tasks, perform a task, or exit TLP (block 64). Otherwise, once 

16 the connection with the server is established (blocks 78, 82), the next step is 

17 to move a task pointer to the beginning of the new task list (block 84). The 

18 MCD 12 downloads the first task in the task list from the in-box for this 

19 user (block 86) and determines whether the downloaded task list data is 

20 valid (block 88). If the data are valid (block 88), the MCD determines 

21 whether that is the end of the task list (block 90). If so, the process ends 

22 (block 92). Otherwise, it loops back and downloads the next task from the 

23 list (block 94). 

24 On the other hand, if data is invalid on the task list (block 88), 

25 the MCD is prompted to determine whether the connection with the server 

26 is still valid (block 96). The MCD will make an entry in the exception log 

27 (block 98) if the connection is no longer valid (block 96), and the process 

28 ends (block 92). Otherwise, when the connection is still valid (block 96), 

29 the MCD increments a retry count (block 100) and determines whether the 

30 incremented retry count has reached its predefined maximum number of 
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1 retries (block 102). Again, if maximum number of retries has been reached 

2 (block 102), an entry in the exception log will be made (block 98) and the 

3 process ends (block 92). 

4 A flow chart for the upload-tasks event 68 is shown in FIG. 6 

5 and is triggered by the TLP (block 106) and starts the process (block 108). 

6 It is first determined whether the MCD is connected to the server (block 

7 110). If not, the user must enter a username and a password to establish a 

8 connection with the server (block 112). However, if the login is 

9 unsuccessful (block 114), the process loops back to display an error 

10 message from the server to the user (block 52), after which the user is given 

11 the option to choose whether to download tasks, upload tasks, perform a 

12 task, or exit TLP (block 64). 

13 If the login is successful (block 1 14), similar to the download- 

14 tasks event 72, the task pointer moves to the beginning of the completed 

15 task list (block 1 18) to ensure that the first completed task is uploaded. The 

16 MCD 12 uploads the first task in the list from the out-box for this user 

17 (block 118), and determines whether the upload is successful (block 120). 

18 The MCD 12 determines whether this is the end of the task list (block 122) 

19 and if the upload was successful (block 120). If so, the process ends (block 

20 124). Otherwise, it loops back and downloads the next task from the list 

21 (block 126). 

22 On the other hand, if the upload proves to be unsuccessful 

23 (block 120), the MCD is prompted to verify that the connection with the 

24 server is still valid (block 128). The MCD will make an entry in the 

25 exception log (block 130) if the connection is not valid (block 130), and the 

26 process ends (block 124). Otherwise, when the connection is still valid 

27 (block 128), the MCD increments a retry count (block 132) and determines 

28 whether the incremented retry count has reached its predefined maximum 

29 number of retries (block 134). Again, if maximum number of retires has 
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1 been reached (block 134), an entry in the exception log will be made (block 

2 130) and the process ends (block 124). 

3 Referring to FIG. 7, which illustrates a flow chart of the 

4 perform-task event 70, the user first selects a task from the task list stored 

5 in the MCD (block 138) and elects to perform the selected task (block 140). 

6 Then, the MCD opens an associated task execution program ("TEP"), 

7 which runs the MCD from this point (block 142). The TEP is generally a 

8 program displaying a specific template or form that is designated to the 

9 selected task with its customization. For example, if the selected task is for 

10 a specific job site having predefined custom checklist items for an 

11 inspection, then the TEP displays the form with the predefined checklist 

12 items for the user to complete the inspection as requested by the job site. 

13 This allows for customization and provides simpler ways to accomplish a 

14 specific task, because the MCD can display the correct forms that match the 

15 selected task to the user. In this example, the user is shown a series of 

16 screens necessary to accomplish the selected task (block 144). However, at 

17 any given point during this process, the user can choose to complete the 

1 8 task or stop and return to the TLP (block 146). 

19 The TEP displays the first checklist item of the selected task 

20 for a response from the user (block 148). The user can then choose to 

21 respond, stop or skip this particular checklist item (block 150). If the user 

22 chooses to stop the TEP (block 152), the TEP ends and passes control back 

23 to the TLP (block 154). On the other hand, if the user does not choose to 

24 stop the TEP (block 152), the user must choose to either skip or respond to 

25 the checklist item. The TEP stores the response for this checklist item if 

26 the user responds to the checklist item (block 155) and proceeds to the next 

27 checklist item once that is done (block 156). However, the next checklist 

28 item is still displayed (block 156) even if the user chooses to skip this 

29 checklist item. It is then determined whether the selected task is completed 

30 (block 158). In other words, the routine determines whether the user has 
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1 completed all of the checklist items. If the task is completed, the TEP ends 

2 itself and passes control of the MCD back to the TLP. Otherwise, the 

3 process loops back for the next checklist item for the user to choose one of 

4 the available options (block 150) and continues until the task is completed. 

5 Four exemplary display screens on the mobile computing 

6 device are shown in FIGS. 8(a) to (d). As an example, assume that the 

7 previous selected task is an inspection of a specific job site, the TEP 

8 displays a first screen showing the name of the inspector, the name of the 

9 building, the address of the building, the location of the building for 

10 inspection, date, and the inspection type (shown in FIG. 8(a)). The user can 

1 1 change any of these fields at this point. In addition, from this first screen, 

12 the user can choose to start the inspection or exit the TEP. If the user 

13 chooses to start the inspection, the next screen is preferably a weekly 

14 inspection form shown in FIG. 8(b), since the first screen displayed a 

15 weekly inspection type. The user can select any of the items listed on the 

16 screen. The next screen shown in FIG. 8(c) is a display of the "signage, 

17 prices, labels correct" item in FIG. 8(b). Finally, FIG. 8(d) shows an 

18 example message screen for sending an email using the MCD. Many other 

19 screens are available and the arrangement of these screens can be changed 

20 and are within the scope of the present invention. 

21 An overall scheme of a session initiated by a user of the client 

22 12 not using a MCD with preloaded software for connection with the server 

23 14 through, for example, the Internet is illustrated in the flow chart of FIG. 

24 9. As previously mentioned, the client can be a personal computer or a 

25 MCD. Both the personal computer and the MCD connect with the server 

26 14 via the Internet in a web browser environment. In this preferred 

27 embodiment, the MCD is not preloaded with anything. Rather, the MCD 

28 has a general wireless Internet connection with a web browser capability. 

29 From that, it is able to respond or send events by visiting various web pages 

30 that are available on the web site. In fact, it is preferred that all setup 
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1 processes, such as a jobsite-setup event, be done in the web browser 

2 environment. 

3 As an example, the process is triggered by the client opening 

4 the home page provided for the implementation of the present invention 

5 (block 160). Although the preferred connection is through a web page 

6 setting, it is not necessary. For example, the present invention can be 

7 implemented using other connections, such as a private network. These 

8 alternative connections are within the scope of the present invention. 

9 However, a XML web page environment is preferred because it can 

10 presently provide the most flexible and simplest environment for the 

11 implementation of the present invention. Regardless, the preferred 

12 environment can change with technology, and other possible alternatives 

13 are also within the scope of the present invention. 

14 The session begins (block 162) with the user first providing a 

15 username and a password in order to log into the server and becomes an 

16 authorized client (block 164). The server next determines whether this is a 

17 valid user (block 166). If not, the server makes an entry in the security log 

18 (block 168) and the process ends (block 170). The user can then choose an 

19 option from the menu (block 172). The options include initiating a job site- 

20 setup event 28, an inspection-templates-setup event 174, work request 

21 event 26, work order event 38, schedules-setup event 32, and contacts-setup 

22 event 176. Once the selected option has been processed, the session checks 

23 if the authorized client wants to continue with choosing the options in the 

24 menu (block 178). If so, it loops back to the option menu (block 172). 

25 Otherwise, the session ends (block 170). 

26 A more detailed description of the jobsite-setup event 28 

27 previously described in FIGS. 3 and 9 is shown in the flow chart of FIG. 

28 10. This event is generally initiated by the user of the client 12 (block 180). 

29 The process begins (block 182) by giving the user of the client a choice of 

30 adding new data, editing existing data, or exiting from the event (block 
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1 184). If exiting the job site-setup event is selected, the process ends at that 

2 point (block 186). The server displays the existing data to the client for 

3 revision for the choice of editing existing data, and the process continues on 

4 to the next step when the option of adding new data is selected (block 188). 

5 The user generally first adds or revises the job attributes, the name and 

6 address of the building facility or other information that helps identify the 

7 building (block 190). The user next adds or revises the identification of the 

8 various parts, sections, or areas of the job site (block 192). 

9 Next, the user sets up the contacts for the job site (block 194), 

10 which will initiate the contact-setup event shown in greater detail in FIG. 

11 11. Then, the user sets up the vendors for the job site (block 196) initiating 

12 the vendor-setup, which is shown in FIG. 12. After that is done, the user 

13 has to set up the inspections initiating the inspection-setup event (block 

14 200) and special actions initiating the special-actions-setup event (block 

15 204). For each inspection that is setup, the user defines a schedule for the 

16 inspection (block 208), which is followed by defining defaults for any 

17 information needed for the job site (block 210). The server 14 saves all the 

18 information onto the database (block 212). It is next determined whether 

19 the user wants to continue setting up another job site (block 214). If so, the 

20 process loops back to the option menu (block 184). Otherwise, the process 

21 ends (block 186). 

22 The contact-setup event 194 is shown in more detail in the 

23 flow chart of FIG. 11, and is generally initiated by the user of the client 

24 (block 216). However, as shown in FIG. 10, it can also follow from 

25 another event. The process begins (block 218) initially by giving the user 

26 an option menu for adding new data, editing existing data, or exiting the 

27 contact-setup event (block 220). If exiting the contact-setup event is 

28 selected, the process will end (block 222). Otherwise, the server displays 

29 the existing data to the client for revision (block 224) when editing existing 

30 data is selected, and the process continues on to the next step when adding 
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1 new data is selected. The user generally first adds or revises the contact 

2 attributes, the name and address of the contact, or other information that 

3 helps identify the contact (block 226). Next, the user defines the method of 

4 communications with the contact (block 228), which follows with the 

5 contact's preferences and communication method for various events (block 

6 230). The user also defines the communication backup preference in cases 

7 when the contact is not accessible (block 232). The type of client used by 

8 the user is also defined within the contact data (block 234). The server then 

9 saves the contact data in the database (block 236) and determines whether 

10 the user wants to continue with the contact-setup event (block 238). If so, 

11 the process goes back to the option menu (block 220). Otherwise, the 

12 process simply ends (block 222). 

13 Referring again to the vendor-setup event 196, it is shown in 

14 more detail in the flow chart of FIG. 12. The vendor-setup event 196 is 

15 generally initiated by the user of the client (block 240), but as shown in 

16 FIG. 10, it can also follow from another event. The process starts (block 

17 242) with the server displaying a job vendor association screen to the client 

18 (block 244), in which the user has a choice to add new data, edit existing 

19 data, or exit the vendor-setup event (block 246). If exiting the vendor-setup 

20 event is selected, the process will end (block 248). Otherwise, the server 

21 allows the client to add a new vendor in the vendor master list stored on the 

22 database (block 250). Alternatively, if the user wants to only edit existing 

23 data, the process moves to the next step. At which time, the user defines 

24 the vendors and the service type for each job site (block 252). In addition, 

25 if applicable, information of sharing permissions for the vendor can also be 

26 added or revised in this step. After the user finished revising the vendor 

27 data, it is then saved onto the database (block 254). It is then determined 

28 whether the user wants to continue in the vendor-setup event (block 256). 

29 The process will end (block 248) if the user does not want to continue in 
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1 the vendor-setup event, otherwise the process loops back to the option 

2 menu (block 246). 

3 With regard to the inspection-setup event 200 (FIG. 10), it is 

4 shown in more detail in FIG. 13, and is generally initiated by the client 

5 (block 258). Similarly, the process starts (block 260) with an option menu 

6 for adding new data, editing existing data, and to exit the inspection-setup 

7 event (block 262). If exiting the inspection-setup event is selected, the 

8 process ends (block 264). Otherwise, the server displays the existing data 

9 to the client for revision if editing existing data is selected (block 266), and 

10 the process continues on to the next step when adding new data is selected. 

11 The user generally first adds or revises the inspection attributes, 

12 description, or other useful information about the inspection (block 268). 

13 For each area of the job site, the user defines the inspection steps using 

14 items from an existing checklist for this job site or from a default inspection 

15 template stored on the database (block 270). The user next revises the 

16 checklist items as needed (block 272), and the checklist-item-setup event 

17 274 is initiated (block 276). The checklist- item-setup event 274 is shown 

18 in FIG. 14, and will be described below in greater detail. The server saves 

1 9 the revised inspection data including inspection records and schedules onto 

20 the database (block 278), and determines whether the user wants to 

21 continue with the inspection-setup event (block 280). If so, the process 

22 goes back to the option menu (block 262). Otherwise, the process ends 

23 (block 264). 

24 The checklist-item-setup event 274 previously mentioned in 

25 FIG. 12 is shown in more detail in the flow chart of FIG. 14. Although this 

26 event follows from the inspection- setup event, the event can be initiated by 

27 the client at any point in the whole system (block 282). The process starts 

28 (block 284) similarly with an option menu for adding new data, editing 

29 existing data, or exiting the contact-setup event (block 286). If the user 

30 chooses to exit the checklist-item-setup event, the process ends (block 288). 
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1 If not, the server displays the existing data to the client for revision (block 

2 290) if the user chooses to edit. If, however, the user chooses to add data, 

3 the process continues to the next step. The user can add or revise the 

4 checklist item attributes, description, or other useful information about the 

5 checklist item (block 292). The user enters or edits questions or statements 

6 to the inspector, and the response type will also be setup along with the 

7 performance rating method for the checklist item (block 294). The user 

8 goes on to setup the performance rating method for the checklist items 

9 (block 296), and the performance-rating-method-setup event 298 is initiated 

10 as a result. The server saves the revised checklist-item data including 

11 records and schedules onto the database (block 300), and determines 

12 whether the user wants to continue with the inspection-setup event (block 

13 302). Again, the process ends (block 288) if the user does not want to 

14 continue. Otherwise, the process loops back to the option menu (block 

15 286). 

16 In accordance with an important aspect of the present 

17 invention, the user can specify the desired performance rating method from 

18 a number of options. This can be done as shown in the flow chart of FIG. 

19 15, and this event is generally triggered by other events (block 304), 

20 although it can also be triggered by the client 12. The process initially 

21 begins (block 306) by giving the user an option menu for adding new data, 

22 editing existing data, or exiting the contact-setup event (block 308). If 

23 exiting the contact-setup event is selected, the process will end (block 310). 

24 Otherwise, the server displays the existing data to the client for revision 

25 (block 312) if editing existing data is selected, and the process continues on 

26 to the next step when adding data is selected. The user then adds or revises 

27 the performance rating method attributes and description in addition to any 

28 other information that may be useful (block 314). Next, the user can add or 

29 revise the performance rating type (block 316), initiating another event 

30 (block 316). More specifically, the performance-rating-type-setup event is 
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1 initiated (block 316). Again, the server saves the revised information onto 

2 the database (block 320), which is followed by a step determining whether 

3 the user wants to continue with the current event (block 322). If so, the 

4 process goes back to the option menu (block 308). Otherwise, the process 

5 simply ends (block 310). 

6 More specifically, with regard to selecting the performance 

7 rating type block 316 and referring to FIG. 16, it is triggered by the 

8 performance-rating-method-setup event (block 324). The process starts 

9 with an option menu of three performance rating types (block 328), 

10 specifically yes/no, multiple options, and numeric scoring. For the yes/no 

1 1 type, there will be only two valid responses (e.g., done/not done) in which 

12 the user will specify the valid responses (block 330). However, the two 

13 valid responses are mutually exclusive, meaning the logic should prevent it 

14 from choosing both at the same time. Next, for the multiple options type, 

15 any number of options (e.g., good, fair, or poor) are possible (block 332), 

16 and the user has to specify each available option in this setup. But only one 

17 option is allowed as a valid response. Similarly, the logic allows only one 

18 option to be chosen. With the numeric type, the user specifies a range of 

19 numeric values having a minimum and a maximum along with a step 

20 interval (e.g., 1 to 10 with an increment of 0.5) (block 334). The process 

21 ends (block 336) when the user finishes selecting and defining the 

22 performance rating type. 

23 The routine for setting up a special-action event 204 is shown 

24 in FIG. 17, which is triggered by the job site-setup event 28 in FIG. 10 

25 (block 338). The process begins (block 340) with the user defining a 

26 special action for an individual checklist item, a group of checklist items, or 

27 a job area (block 342). The user can also define special actions for each of 

28 the three performance rating types discussed in FIG. 16 (block 344). 

29 Alternatively, if the special actions are based on a group, the total score for 

30 that group can be used as a threshold comparison for the special actions 
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1 (block 344). Next, the user can set up one or more actions for each special 

2 action, such as notifying one or more contacts, creating a work request or 

3 work order and notifying the contacts (block 346). And each special action 

4 can also include a response time (block 346). The user can also setup the 

5 special action to be triggered by the response from the three performance 

6 rating type. For the yes/no type of action, it can be triggered by either of 

7 the events (block 348). Similarly, within the multiple options type, the 

8 action can be triggered by the valid response (block 350). Finally, for the 

9 numeric type, the user can use a range method and define the range that 

10 triggers the special actions (block 352). With that, the process ends (block 

11 354). 

12 To setup the inspection-templates-setup event 1 74 as 

13 described in FIG. 9, the steps of the flow chart shown in FIG. 18 are carried 

14 out. The event can also be triggered by the user of the client 12 who 

15 chooses this option on the web page (block 356). The process starts (block 

16 358) with an option menu of adding new data, editing existing data, or 

17 exiting from the event (block 360). If exiting the job site-setup event is 

18 selected, the process ends (block 362). Otherwise, either the server 

19 displays the existing data to the client for revision if the edit option is 

20 chosen (block 364), or the process continues on to the next step if the add 

21 option is chosen. The user then adds or revises the template attributes and 

22 description, or other information that may be useful (block 366). The user 

23 next defines the inspection template as the inspection steps using items 

24 from the checklist previously setup in FIG. 14 (block 368). The checklist 

25 items can either be from an existing checklist or a default inspection 

26 template stored on the database. These are the checklist items that are 

27 displayed for a selected job area (block 192) in the previous discussion of 

28 the perform-task event in FIG. 10. The user at this time can edit the 

29 checklist items (block 370). The server then saves the revised inspection 

30 template data onto the database (block 372), and determines whether the 
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1 user wants to continue with the inspection-template-setup event (block 

2 374). If so, the process returns back to the option menu (block 360). 

3 Otherwise, the process simply ends (block 362). 

4 To setup the schedules 32 (FIG. 3), and referring to the flow 

5 chart of FIG. 19, this event is generally triggered by an external process, 

6 such as the one described previously in FIG. 9 (block 376). However, the 

7 event can also be triggered by the user of the client 12 choosing this option 

8 on the web page. The process starts (block 378) with an option menu of 

9 adding new data, editing existing data, or exiting from the event (block 

10 380). This event allows the user to setup different schedules and associate 

1 1 them with a selected event, such as an inspection event. The process ends 

12 (block 382) if the user chooses the exit option. However, if the user 

1 3 chooses the edit option, the server displays the existing schedule data stored 

14 in the database to the client for revision (block 384). Alternatively, the 

1 5 process continues on to the next step if the add option is selected, which is 

16 adding and revising the schedule attributes and description or other useful 

17 information (block 386). The user next defines the schedule parameters, 

1 8 such as the frequency of the event and whether it is rule based or fixed 

19 dates based (block 388). The server saves the revised schedule data onto 

20 the database (block 390), and again determines whether the user wants to 

21 continue with the schedule-setup event (block 392). If so, the process goes 

22 back to the option menu (block 380). Otherwise, the process ends (block 

23 382). 

24 The detailed steps of carrying out an inspection-processing 

25 event 40 from FIG. 3 is shown in the flow chart of FIG. 20. This event is 

26 generally triggered by the client sending inspection data to the server (block 

27 394) either on the web page or the MCD. More specifically, the client 

28 generally sends inspection data to the server, for example, once an 

29 inspection is completed by the user on the MCD. The process begins 

30 (block 396) by validating the sent data (block 398). If it is found that the 
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1 data is invalid (block 400), the server will make an entry in the exception 

2 log (block 402) and the process ends (block 404). On the other hand, if the 

3 data is valid (block 400), the server will save the inspection data on the 

4 database (block 406). The inspection data is then compared with the 

5 allowed pre-defined tolerances from the performance-rating data (block 

6 408) to determine whether the data is within the tolerances (block 410). If 

7 so, the server initiates a notification event 34 (block 412) that allows the 

8 server to send a message informing a contact person of the job site of the 

9 inspection being within preset tolerances. 

10 If the routine does not end (block 404), meaning that the data 

11 is not within the predefined tolerances (block 410), it is next determined 

12 whether any special action is required (block 414). Whether any special 

13 action is required depends on the data that were previously defined in all 

14 the setup events. The clearinghouse evaluates the data and makes decisions 

15 on certain actions based on all the data stored in the database, and sends 

16 them to the server for performance when necessary. If no special action is 

17 required (block 414), the server again initiates a notification event 34 to the 

18 clearinghouse for sending a message to the contact of the status of this 

19 inspection (block 416). However, if special actions are needed (block 414), 

20 the server will either initiate a work-request event 26 (block 418) or a work- 

21 order event 38 (block 420), depending on the instructions from the data 

22 stored in database. When either events are initiated, a message will be sent 

23 to the contact person initiating the notification event 34 (block 422 and 

24 424) to bring the process to an end (block 404). 

25 With regard to the notification event described in connection 

26 with FIG. 20, and referring to the flow chart of FIG. 21, the notification 

27 event can be initiated at any time during operation of the system. Basically, 

28 it is initiated whenever a message is being sent to a specific recipient, the 

29 identity of which is dependent on information stored in the database. The 

30 process starts (block 426) with the server retrieving the recipient 
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1 information from the clearinghouse (block 428), which was gathered from 

2 the database. The clearinghouse sends the server only selected data that is 

3 needed in order to process the notification event. From that information, 

4 the server selects one of the four methods of communication provided as 

5 previously defined in the setup events (block 430). Specifically, the 

6 methods preferably include fax (block 432), email (block 434), phone 

7 (block 436), digital pager (block 438), and alphanumeric (block 440) as 

8 examples. However, any of these methods can be excluded, and other 

9 methods can also be included. The server sends the recipient a message 

10 according to whatever method that is indicated from the clearinghouse 

11 (blocks 432 to 440). Next, the server examines the information from the 

12 clearinghouse to see if the message should be sent to multiple devices 

13 (block 442). If so, the process goes back to the selection of the 

14 communication method step (block 430) and starts over again. Once all the 

15 requested communication methods have been utilized (block 444), the 

16 process ends (block 446). 

17 With regard to a work request, it can be made according to 

18 the routine shown in the flow chart of FIGS. 22(a) through 22(c). The 

19 event is usually triggered by other events, but can also be triggered by the 

20 user choosing this option on the web page or the MCD (block 448). The 

21 process begins (block 450) with the server displaying to the client an option 

22 menu with the choices to add new data, edit existing data, or exit the event 

23 (block 452). If the client wants to exit the event, the process will end 

24 (block 454) (FIG. 22(b)). If the client selects to add new data, the server 

25 creates a list of job sites that are authorized to the user (block 456). It is 

26 next determined whether the list is empty (block 458). If the list is not 

27 empty (block 458), it is next determined whether the required job is in the 

28 list (block 460). If the list is empty (block 458), the user is notified of the 

29 list being empty (block 462). 
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1 Furthermore, after the notification to the user (block 462) or 

2 the required job is not in the list (block 460), the server inquires whether 

3 the user wants to specify a location (block 464) as shown in FIG. 22(b). If 

4 the user does not want to specify a location (block 464), the server next 

5 inquires whether the user wants to send a message (block 466). If not, the 

6 process ends at this point (block 454). Otherwise, the user can compose a 

7 message to the default contact for a work ticket without any job 

8 information, or an alternative contact of the user's choice (block 468). As a 

9 result, the notification event is initiated because a message is being sent 

10 (block 470), and the process comes to an end (block 454). 

1 1 However, if the user wants to specify a location (block 464), 

12 the user can enter the location information and description for the work to 

13 be performed with the price, payment, terms, approval notice, and due date 

14 and time (block 472). At that point, the work request without a job 

15 association will be saved on the database, and the default contact will be 

16 notified of the work request (block 474). The notification event 34 is 

17 initiated by the notification to the default contact (block 476). The last step 

18 is to determine whether the user wants to notify another contact (block 

19 478). The user picks another contact from a list from the server (block 

20 480), and the notification event is initiated again (block 482). Otherwise, 

21 the process ends (block 454). 

22 Returning to the beginning of the process in FIG. 22(a), if the 

23 required job is in the list (block 460) and the user selects a job from the list 

24 (block 484) or an existing work request is displayed to the user (block 487), 

25 the user can enter or edit the description of the work to be preformed with 

26 the due date and time (block 486). The server determines whether the 

27 client wants to contact the default authorized client for this work request 

28 (block 488). If not, the client picks another authorized client from the 

29 contact list for the job site (block 490). The server then saves the work 

30 request with the selected authorized client onto the database (block 492). 
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1 Next, the server sends the details of the work request to the authorized 

2 client (block 494), initiating another notification event (block 496). The 

3 process ends at this point (block 454). 

4 If the work-request event originates from the MCD, which is 

5 different from initiating the event on the web page, the flow chart of FIG. 

6 22(c) applies. When the work-request event is triggered by the MCD 

7 (block 498), the process starts (block 500) with two options of adding new 

8 data or editing existing data, and is generally done during an inspection. 

9 For adding new data, the user creates and edits one or more work requests 

10 for the job site for which the inspection is in progress (block 502). The 

11 MCD will scan the inspection data to establish whether the user has 

12 permission to create such a work request (block 504). If the user does not 

13 have permission (block 506), the MCD notifies the user (block 508) and 

14 asks whether the user wants to send a message (block 510). If so, the user 

15 composes the message to the primary contact of the job site (block 512), 

16 which the server will send to the contact using the notification event 34 

17 (block 514). As shown in FIG. 22(a), the process then ends (block 454). 

18 Assuming the server displayed the existing data to the client 

19 for revision (block 516) or the client has permission to create a work 

20 request (block 506), the user will enter and edit the work request as needed, 

21 which might include the description, price, payment terms, approval notice, 

22 and due date and time (block 518). This information is then saved to the 

23 database by the server after the client has finished revising (block 520), and 

24 the revised data is sent to the designated authorized client (block 494) using 

25 the notification event 34 (block 496), bringing the process to an end (block 

26 454). The use of the authorized client must now process the work request, 

27 which is shown in FIG. 23. 

28 Turning now to FIG. 23, a flow chart of the work-request- 

29 processing event for the designated authorized client of a work request is 

30 shown and generally indicated as 522. The event begins (block 524) with 
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1 triggering from either the authorized client accessing the web page (block 

2 526) or data received (block 528). If this is a user initiated session, the 

3 server determines whether the client gave a record identifier for the work 

4 . request being processed (block 530). If the client did not supply the server 

5 with a record identifier (block 530), the server prepares a list of all open 

6 work requests to the authorized client for selection (block 532). The user of 

7 the authorized client selects a work request from the list (block 534), and 

8 the server will display the selected work request to the user (block 536). 

9 The user must either accept or reject the selected work request (block 538). 

10 Alternatively, when the data is sent from an authorized client to the server 

11 using a MCD, for example, the server validates the received data (block 

12 540). If the data is not valid (block 542), the server makes an entry in the 

13 exception log (block 544) and the process ends (block 546). If the data is 

14 valid, the user must then either accept or reject the work request. 

15 If the user of the authorized client accepts the work request, 

16 an approval code must be entered by the user, and then validate the 

17 approval by entering either a password or pin number (block 548). The 

18 server will then save the information onto the database and create a work 

19 order for the approved work request (block 550), which will initiate the 

20 work-order event 38 (block 552). If, on the other hand, the work request is 

21 rejected, the user preferably requests an explanation and must also validate 

22 the request with password or pin number (block 554). The server next 

23 determines whether the user of the client asks for a revised work request 

24 (block 556). If not, the process ends (block 546). If the user does asks for 

25 a revised work request (block 556), the server updates the database with the 

26 revised work request (block 558). As a result, a notification message will 

27 be sent to the contact, initiating the notification event (block 560). The 

28 process then ends (block 546). 

29 With regard to the work-order event, and referring to the flow 

30 chart of FIGS. 24(a) and 24(b), this event is triggered by the user choosing 
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1 this option or by other events (block 562). The process begins (block 564) 

2 with an option menu from which the user can select to add new data, edit 

3 existing data, or exit the current event (block 566). If the user exits the 

4 current event, the process ends (block 568). If the user elects to add new 

5 data, the server creates a list of job sites authorized to the current user to 

6 add new work orders (block 570). It is next determined whether the list is 

7 empty (block 572). If the list is not empty (block 572), it is determined 

8 whether the required job is in the list (block 574). If the list is empty (block 

9 572), the user is notified of the list being empty (block 576). After the user 

10 has been notified (block 576) or the required job is not in the list (block 

1 1 574), the server asks the user if a work request should be created (block 

12 578). If the user elects not to create a work request (block 580), the routine 

13 ends (block 568). Otherwise, a work request is created initiating the work- 

14 request event (block 582) if the user decides to create one (block 580). 

1 5 Returning back to the beginning of the process in FIG. 24(a), 

16 if the required job is in the list (block 574) and the user selects a job from 

17 the list (block 584) or an existing work request is displayed to the user 

18 (block 586), the user can enter or edit the description of the work to be 

19 preformed with the due date and time of the work order (block 588). The 

20 server inquires whether the client wants to contact the default recipient of 

21 the work order (block 590). If not, the client picks another recipient from 

22 the contact list for the job site (block 592). The server then saves the work 

23 order with the selected recipient in the database (block 594). Next, the 

24 server sends the details of the work order to the recipient (block 596), 

25 initiating a notification event (block 598). The process ends at this point 

26 for the work order event (block 568). 

27 To process a work order, and referring to the flow chart of 

28 FIG. 25, the work-order-processing event begins (block 602) and is 

29 triggered by either the recipient using an authorized client to access the web 

30 page (block 604) or data received (block 606). If this is a user initiated 
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1 session, the server determines whether there is a record identifier available 

2 for the work order (block 608). If the authorized client did not supply the 

3 server with a record identifier (block 608), the server prepares a list of all 

4 open work orders for the authorized client for selection (block 610). The 

5 recipient selects a work order from the list (block 612), and the server 

6 displays the selected work order to the recipient (block 614). Alternatively, 

7 when the data is sent from a recipient using a MCD to the server, for 

8 example, the server validates the received data (block 616). If the data is 

9 not valid (block 618), the server makes an entry in the exception log (block 

10 620) and the process ends (block 622). Assuming that the data is valid 

11 (block 618) or that the user updated the existing work order, the server 

12 updates this information onto the database (block 624). At this point, a 

13 notification is sent to the contact person of the job site using the notification 

14 event (block 626), and the process ends (block 622). 

15 In accordance with another important aspect of the present 

16 invention and referring to FIG. 26, the clearinghouse keeps a scheduling 

17 process to respond to the scheduled items from a client or an event. The 

18 clearinghouse preferably runs this process continuously. It begins (block 

19 628) with a timer (block 630) that triggers the process (block 632). The 

20 clearinghouse determines whether the process should end according to the 

21 timer (block 634). If so, the process ends (block 636). However, if it is 

22 determined that the process should continue (block 634), the clearinghouse 

23 reads a scheduled event from a schedule list (block 638) and determines 

24 whether this is the end of the list (block 640). If it is the end of the list 

25 (block 640), the clearinghouse waits until it is again triggered by the timer 

26 (block 632). On the other hand, if it is not the end of the list, the 

27 clearinghouse responds to the scheduled event (block 642). How the 

28 clearinghouse will respond to the event depends upon the type of event. In 

29 addition to responding to the event in the predefined process proposed in 

30 each event, the clearinghouse further sends a notification to the default 
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1 contact of the schedule event using the notification event (block 644). The 

2 process then returns to read the next scheduled event (block 638), and 

3 reruns the process from that point again. 

4 The general scheme of the monitoring process is shown in the 

5 flow chart of FIG. 27, which is similar to the schedule process previously 

6 discussed. The clearinghouse also keeps a monitoring process that tracks 

7 any overdue items and responds to the overdue items accordingly. The 

8 clearinghouse also preferably runs this routine continuously. It begins 

9 (block 646) with a timer (block 648) that triggers the process (block 650). 

10 The clearinghouse determines whether the process should end according to 

11 the timer (block 652). If so, the process simply ends at this point (block 

12 654). However, if it is determined that the process should continue (block 

13 652), the clearinghouse reads a check sheet item list that includes any event 

14 with a due date and time (block 656). The clearinghouse further checks if it 

15 has reached the end of the list (block 658). If it is the end of the list (block 

16 658), the clearinghouse waits until it is triggered by the timer again (block 

17 650). On the other hand, if it is not the end of the list (block 658), the 

18 clearinghouse determines whether the item is overdue (block 660). If not, 

19 the clearinghouse again waits until it is triggered by the timer (block 650). 

20 If the item is overdue, the clearinghouse responds to the scheduled event 

21 (block 642). The clearinghouse responds to the overdue item by sending a 

22 notification to the contact regarding the overdue item using the notification 

23 event (block 662), and the process ends (block 654). 

24 From the foregoing description, it should be understood that 

25 an improved method and system for managing maintenance of building 

26 facilities has been shown and described, which have many desirable 

27 attributes and advantages. The system and method integrate the whole 

28 maintenance management of building facilities into a single system with 

29 minimal human intervention. Because of the superior design of the system, 

30 the present invention allows for intricate maintenance customization for 
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1 each building facility while maintaining precision and organization in the 

2 management system. 

3 While various embodiments of the present invention have 

4 been shown and described, it should be understood that other modifications, 

5 substitutions and alternatives are apparent to one of ordinary skill in the art. 

6 Such modifications, substitutions and alternatives can be made without 

7 departing from the spirit and scope of the invention, which should be 

8 determined from the appended claims. 

9 Various features of the invention are set forth in the appended 
10 claims. 
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